home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1993
/
Internet Info CD-ROM (Walnut Creek) (1993).iso
/
inet
/
internet-drafts
/
draft-ietf-bridge-objects-01.txt
< prev
next >
Wrap
Text File
|
1993-03-03
|
79KB
|
2,203 lines
Internet Draft Bridge MIB October 1992
Definitions of Managed Objects
for Bridges
26 October 17:53:30 EST 1992
Draft Expiration Date: March 1993
Eric B. Decker
cisco Systems, Inc.
cire@cisco.com
Paul Langille & Anil Rijsinghani
Digital Equipment Corporation
anil@levers.enet.dec.com
langille@edwin.enet.dec.com
Keith McCloghrie
Hughes LAN Systems, Inc.
kzm@hls.com
1. Abstract
This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP
based internets. In particular it defines objects for
managing MAC bridges based on the IEEE 802.1D-1990 standard
between Local Area Network (LAN) segments. Provisions are
made for support of transparent bridging. Provisions are also
made so that these objects apply to bridges connected by
subnetworks other than LAN segments.
2. Status of this Memo
This document will be submitted to the RFC editor as an
extension to the SNMP MIB. Distribution of this memo is
unlimited. Please send comments to the authors.
Decker/Langille/Rijsinghani/McCloghrie [Page 1]
Internet Draft Bridge MIB October 1992
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other
than as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each
Internet Draft directory to learn the current status of this
or any other Internet Draft.
3. The Network Management Framework
The Internet-standard Network Management Framework consists of
three components. They are:
RFC 1155 which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of
management. RFC 1212 defines a more concise description
mechanism, which is wholly consistent with the SMI.
RFC 1156 which defines MIB-I, the core set of managed
objects for the Internet suite of protocols. RFC 1213,
defines MIB-II, an evolution of MIB-I based on
implementation experience and new operational requirements.
RFC 1157 which defines the SNMP, the protocol used for
network access to managed objects.
The Framework permits new objects to be defined for the
purpose of experimentation and evaluation.
4. Objects
Managed objects are accessed via a virtual information store,
termed the Management Information Base or MIB. Objects in the
MIB are defined using the subset of Abstract Syntax Notation
One (ASN.1) [7] defined in the SMI. In particular, each
object has a name, a syntax, and an encoding. The name is an
Decker/Langille/Rijsinghani/McCloghrie [Page 2]
Internet Draft Bridge MIB October 1992
object identifier, an administratively assigned name, which
specifies an object type. The object type together with an
object instance serves to uniquely identify a specific
instantiation of the object. For human convenience, we often
use a textual string, termed the OBJECT DESCRIPTOR, to also
refer to the object type.
The syntax of an object type defines the abstract data
structure corresponding to that object type. The ASN.1
language is used for this purpose. However, the SMI [3]
purposely restricts the ASN.1 constructs which may be used.
These restrictions are explicitly made for simplicity.
The encoding of an object type is simply how that object type
is represented using the object type's syntax. Implicitly
tied to the notion of an object type's syntax and encoding is
how the object type is represented when being transmitted on
the network.
The SMI specifies the use of the basic encoding rules of ASN.1
[8], subject to the additional requirements imposed by the
SNMP.
4.1. Format of Definitions
Section 6 contains the specification of all object types
contained in this MIB module. The object types are defined
using the conventions defined in the SMI, as amended by the
extensions specified in [9,10].
Decker/Langille/Rijsinghani/McCloghrie [Page 3]
Internet Draft Bridge MIB October 1992
5. Overview
A common device present in many networks is the Bridge. This
device is used to connect Local Area Network segments below
the network layer.
There are two major modes defined for this bridging;
transparent and source route. The transparent method of
bridging is defined in the draft IEEE 802.1d
specification[11]. This memo defines those objects needed for
the management of a bridging entity operating in the
transparent mode, as well as some objects applicable to all
types of bridges.
To be consistent with IAB directives and good engineering
practice, an explicit attempt was made to keep this MIB as
simple as possible. This was accomplished by applying the
following criteria to objects proposed for inclusion:
(1) Start with a small set of essential objects and add only
as further objects are needed.
(2) Require objects be essential for either fault or
configuration management.
(3) Consider evidence of current use and/or utility.
(4) Limit the total of objects.
(5) Exclude objects which are simply derivable from others in
this or other MIBs.
(6) Avoid causing critical sections to be heavily
instrumented. The guideline that was followed is one
counter per critical section per layer.
5.1. Structure of MIB
Objects in this MIB are arranged into groups. Each group is
organized as a set of related objects. The overall structure
and assignment of objects to their groups is shown below.
Where appropriate the corresponding IEEE 802.1d[11] management
object name is also included.
Decker/Langille/Rijsinghani/McCloghrie [Page 4]
Internet Draft Bridge MIB October 1992
Bridge MIB Name IEEE 802.1d Name
dot1dBridge
dot1dBase
BridgeAddress Bridge.BridgeAddress
NumPorts Bridge.NumberOfPorts
Type
PortTable
Port BridgePort.PortNumber
IfIndex
Circuit
DelayExceededDiscards .DiscardTransitDelay
MtuExceededDiscards .DiscardOnError
dot1dStp
ProtocolSpecification
Priority SpanningTreeProtocol
.BridgePriority
TimeSinceTopologyChange .TimeSinceTopologyChange
TopChanges .TopologyChangeCount
DesignatedRoot .DesignatedRoot
RootCost .RootCost
RootPort .RootPort
MaxAge .MaxAge
HelloTime .HelloTime
HoldTime .HoldTime
ForwardDelay .ForwardDelay
BridgeMaxAge .BridgeMaxAge
BridgeHelloTime .BridgeHelloTime
BridgeForwardDelay .BridgeForwardDelay
PortTable
Port SpanningTreeProtocolPort
.PortNumber
Priority .PortPriority
State .SpanningTreeState
Enable
PathCost .PortPathCost
DesignatedRoot .DesignatedRoot
DesignatedCost .DesignatedCost
DesignatedBridge .DesignatedBridge
DesignatedPort .DesignatedPort
ForwardTransitions
Decker/Langille/Rijsinghani/McCloghrie [Page 5]
Internet Draft Bridge MIB October 1992
dot1dTp
LearnedEntryDiscards BridgeFilter.DatabaseSize
.NumDynamic,NumStatic
AgingTime BridgeFilter.AgingTime
FdbTable
Address
Port
Status
PortTable
Port
MaxInfo
InFrames BridgePort.FramesReceived
OutFrames .ForwardOutbound
InDiscards .DiscardInbound
dot1dStatic
StaticTable
Address
ReceivePort
AllowedToGoTo
Status
The following IEEE 802.1d management objects have not been
included in the Bridge MIB for the indicated reasons.
IEEE 802.1d Object Disposition
Bridge.BridgeName Same as sysDescr (MIB II)
Bridge.BridgeUpTime Same as sysUpTime (MIB II)
Bridge.PortAddresses Same as ifPhysAddress (MIB II)
BridgePort.PortName Same as ifDescr (MIB II)
BridgePort.PortType Same as ifType (MIB II)
BridgePort.RoutingType Derivable from the implemented
groups
SpanningTreeProtocol
.BridgeIdentifier Combination of dot1dStpPriority
and dot1dBaseBridgeAddress
.TopologyChange Since this is transitory, it
is not considered useful.
SpanningTreeProtocolPort
.Uptime Same as ifLastChange (MIB II)
.PortIdentifier Combination of dot1dStpPort
and dot1dStpPortPriority
Decker/Langille/Rijsinghani/McCloghrie [Page 6]
Internet Draft Bridge MIB October 1992
.TopologyChangeAcknowledged Since this is transitory, it
is not considered useful.
.DiscardLackOfBuffers Redundant
Transmission Priority These objects are not required
as per the Pics Proforma and
not considered useful.
.TransmissionPriorityName
.OutboundUserPriority
.OutboundAccessPriority
5.1.1. The dot1dBase Group
This mandatory group contains the objects which are applicable
to all types of bridges.
5.1.2. The dot1dStp Group
This group contains the objects that denote the bridge's state
with respect to the Spanning Tree Protocol. If a node does
not implemented the Spanning Tree Protocol, this group will
not be implemented.
5.1.3. The dot1dSr Group
This group contains the objects that describe the entity's
state with respect to source route bridging. If source
routing is not supported this group will not be implemented.
This group is applicable to source route only, and SRT
bridges. This group will be described in a separate document
applicable only to source route bridging.
5.1.4. The dot1dTp Group
This group contains objects that describe the entity's state
with respect to transparent bridging. If transparent bridging
is not supported this group will not be implemented. This
group is applicable to transparent only and SRT bridges.
5.1.5. The dot1dStatic Group
This group contains objects that describe the entity's state
with respect to destination-address filtering. If
destination-address filtering is not supported this group will
Decker/Langille/Rijsinghani/McCloghrie [Page 7]
Internet Draft Bridge MIB October 1992
not be implemented. This group is applicable to any type of
bridge which performs destination-address filtering.
5.2. Relationship to Other MIBs
As described above, some IEEE 802.1d management objects have
not been included in this MIB because they overlap with
objects in other MIBs applicable to a bridge implementing this
MIB. In particular, it is assumed that a bridge implementing
this MIB will also implement (at least) the 'system' group and
the 'interfaces' group defined in MIB-II [6].
5.2.1. Relationship to the 'system' group
In MIB-II, the 'system' group is defined as being mandatory
for all systems such that each managed entity contains one
instance of each object in the 'system' group. Thus, those
objects apply to the entity as a whole irrespective of whether
the entity's sole functionality is bridging, or whether
bridging is only a subset of the entity's functionality.
5.2.2. Relationship to the 'interfaces' group
In MIB-II, the 'interfaces' group is defined as being
mandatory for all systems and contains information on an
entity's interfaces, where each interface is thought of as
being attached to a `subnetwork'. (Note that this term is not
to be confused with `subnet' which refers to an addressing
partitioning scheme used in the Internet suite of protocols.)
The term 'segment' is used in this memo to refer to such a
subnetwork, whether it be an Ethernet segment, a 'ring', a WAN
link, or even an X.25 virtual circuit.
Implicit in this Bridge MIB is the notion of ports on a
bridge. Each of these ports is associated with one interface
of the 'interfaces' group, and in most situations, each port
is associated with a different interface. However, there are
situations in which multiple ports are associated with the
same interface. An example of such a situation would be
several ports each corresponding one-to-one with several X.25
virtual circuits but all on the same interface.
Each port is uniquely identified by a port number. A port
number has no mandatory relationship to an interface number,
Decker/Langille/Rijsinghani/McCloghrie [Page 8]
Internet Draft Bridge MIB October 1992
but in the simple case a port number will have the same value
as the corresponding interface's interface number. Port
numbers are in the range (1..dot1dBaseNumPorts).
Some entities perform other functionality as well as bridging
through the sending and receiving of data on their interfaces.
In such situations, only a subset of the data sent/received on
an interface is within the domain of the entity's bridging
functionality. This subset is considered to be delineated
according to a set of protocols, with some protocols being
bridged, and other protocols not being bridged. For example,
in an entity which exclusively performed bridging, all
protocols would be considered as being bridged, whereas in an
entity which performed IP routing on IP datagrams and only
bridged other protocols, only the non-IP data would be
considered as being bridged.
Thus, this Bridge MIB (and in particular, its counters) are
applicable only to that subset of the data on an entity's
interfaces which is sent/received for a protocol being
bridged. All such data is sent/received via the ports of the
bridge.
5.3. Textual Conventions
The datatypes, MacAddress, BridgeId and Timeout, are used as
textual conventions in this document. These textual
conventions have NO effect on either the syntax nor the
semantics of any managed object. Objects defined using these
conventions are always encoded by means of the rules that
define their primitive type. Hence, no changes to the SMI or
the SNMP are necessary to accommodate these textual
conventions which are adopted merely for the convenience of
readers.
6. Changes from RFC 1286
(1) Updated all text to remove references to source route
bridging where not applicable. SR MIB will be a separate
document.
(2) Removed dot1dSrPortTable. Retained OID definition of
dot1dSr.
Decker/Langille/Rijsinghani/McCloghrie [Page 9]
Internet Draft Bridge MIB October 1992
(3) Updated all references of "draft P802.1d/D9" to "IEEE
802.1D-1990".
(4) Updated bibliography.
(5) Added clarification to description of dot1dPortPathCost.
(6) Put recommended default in description of
dot1dStaticAllowedToGoTo.
(7) Put recommended default in description of
dot1dStaticStatus.
(8) Put recommended default in description of
dot1dTpAgingTime. Specified range of (10..1000000).
(9) Updated all port number syntaxes, when used as index, to
use the range (1..65535).
(10) Updated definition of dot1dTpPortInFrames and
dot1dTpPortOutFrames.
(11) Added text to the traps indicating that they are
optional.
(12) Clarified definition of dot1dStpForwardDelay.
Decker/Langille/Rijsinghani/McCloghrie [Page 10]
Internet Draft Bridge MIB October 1992
7. Definitions
RFCXXXX-MIB DEFINITIONS ::= BEGIN
IMPORTS
Counter, TimeTicks
FROM RFC1155-SMI
mib-2
FROM RFC1213-MIB
OBJECT-TYPE
FROM RFC-1212
TRAP-TYPE
FROM RFC-1215;
-- All representations of MAC addresses in this MIB Module use,
-- as a textual convention (i.e. this convention does not affect
-- their encoding), the data type:
MacAddress ::= OCTET STRING (SIZE (6)) -- a 6 octet address in
-- the "canonical" order
-- defined by IEEE 802.1a, i.e., as if it were transmitted least
-- significant bit first, even though 802.5 (in contrast to other
-- 802.x protocols) requires MAC addresses to be transmitted most
-- significant bit first.
--
-- 16-bit addresses, if needed, are represented by setting their
-- upper 4 octets to all 0's, i.e., AAFF would be represented
-- as 00000000AAFF.
-- Similarly, all representations of Bridge-Id in this MIB Module
-- use, as a textual convention (i.e. this convention does not affect
-- their encoding), the data type:
BridgeId ::= OCTET STRING (SIZE (8)) -- the Bridge-Identifier as
-- used in the Spanning Tree
-- Protocol to uniquely identify a bridge. Its first two octets
-- (in network byte order) contain a priority value and its last
-- 6 octets contain the MAC address used to refer to a bridge in a
-- unique fashion (typically, the numerically smallest MAC address
-- of all ports on the bridge).
Decker/Langille/Rijsinghani/McCloghrie [Page 11]
Internet Draft Bridge MIB October 1992
-- Several objects in this MIB module represent values of timers
-- used by the Spanning Tree Protocol. In this MIB, these timers
-- have values in units of hundreths of a second (i.e. 1/100 secs).
-- These timers, when stored in a Spanning Tree Protocol's BPDU,
-- are in units of 1/256 seconds. Note, however, that 802.1D-1990
-- specifies a settable granularity of no more than 1 second for
-- these timers. To avoid ambiguity, a data type is defined here
-- as a textual convention and all representation of these timers
-- in this MIB module are defined using this data type. An algorithm
-- is also defined for converting between the different units, to
-- ensure a timer's value is not distorted by multiple conversions.
-- The data type is:
Timeout ::= INTEGER -- a STP timer in units of 1/100 seconds
-- To convert a Timeout value into a value in units of
-- 1/256 seconds, the following algorithm should be used:
--
-- b = floor( (n * 256) / 100)
--
-- where:
-- floor = quotient [ignore remainder]
-- n is the value in 1/100 second units
-- b is the value in 1/256 second units
--
-- To convert the value from 1/256 second units back to
-- 1/100 seconds, the following algorithm should be used:
--
-- n = ceiling( (b * 100) / 256)
--
-- where:
-- ceiling = quotient [if remainder is 0], or
-- quotient + 1 [if remainder is non-zero]
-- n is the value in 1/100 second units
-- b is the value in 1/256 second units
--
-- Note: it is important that the arithmetic operations are done
-- in the order specified (i.e., multiply first, divide second).
Decker/Langille/Rijsinghani/McCloghrie [Page 12]
Internet Draft Bridge MIB October 1992
dot1dBridge OBJECT IDENTIFIER ::= { mib-2 17 }
-- groups in the Bridge MIB
dot1dBase OBJECT IDENTIFIER ::= { dot1dBridge 1 }
dot1dStp OBJECT IDENTIFIER ::= { dot1dBridge 2 }
dot1dSr OBJECT IDENTIFIER ::= { dot1dBridge 3 }
-- separately documented
dot1dTp OBJECT IDENTIFIER ::= { dot1dBridge 4 }
dot1dStatic OBJECT IDENTIFIER ::= { dot1dBridge 5 }
-- the dot1dBase group
-- Implementation of the dot1dBase group is mandatory for all
-- bridges.
dot1dBaseBridgeAddress OBJECT-TYPE
SYNTAX MacAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The MAC address used by this bridge when it must
be referred to in a unique fashion. It is
recommended that this be the numerically smallest
MAC address of all ports that belong to this
bridge. However it is only required to be unique.
When concatenated with dot1dStpPriority a unique
BridgeIdentifier is formed which is used in the
Spanning Tree Protocol."
REFERENCE
"IEEE 802.1D-1990: Sections 6.4.1.1.3 and 3.12.5"
::= { dot1dBase 1 }
dot1dBaseNumPorts OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of ports controlled by this bridging
entity."
Decker/Langille/Rijsinghani/McCloghrie [Page 13]
Internet Draft Bridge MIB October 1992
REFERENCE
"IEEE 802.1D-1990: Section 6.4.1.1.3"
::= { dot1dBase 2 }
dot1dBaseType OBJECT-TYPE
SYNTAX INTEGER {
unknown(1),
transparent-only(2),
sourceroute-only(3),
srt(4)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Indicates what type of bridging this bridge can
perform. If a bridge is actually performing a
certain type of bridging this will be indicated by
entries in the port table for the given type."
::= { dot1dBase 3 }
-- The Generic Bridge Port Table
dot1dBasePortTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1dBasePortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A table that contains generic information about
every port that is associated with this bridge.
Transparent, source-route, and srt ports are
included."
::= { dot1dBase 4 }
dot1dBasePortEntry OBJECT-TYPE
SYNTAX Dot1dBasePortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of information for each port of the
bridge."
REFERENCE
"IEEE 802.1D-1990: Section 6.4.2, 6.6.1"
INDEX { dot1dBasePort }
::= { dot1dBasePortTable 1 }
Decker/Langille/Rijsinghani/McCloghrie [Page 14]
Internet Draft Bridge MIB October 1992
Dot1dBasePortEntry ::=
SEQUENCE {
dot1dBasePort
INTEGER,
dot1dBasePortIfIndex
INTEGER,
dot1dBasePortCircuit
OBJECT IDENTIFIER,
dot1dBasePortDelayExceededDiscards
Counter,
dot1dBasePortMtuExceededDiscards
Counter
}
dot1dBasePort OBJECT-TYPE
SYNTAX INTEGER (1..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The port number of the port for which this entry
contains bridge management information."
::= { dot1dBasePortEntry 1 }
dot1dBasePortIfIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of the instance of the ifIndex object,
defined in MIB-II, for the interface corresponding
to this port."
::= { dot1dBasePortEntry 2 }
dot1dBasePortCircuit OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"For a port which (potentially) has the same value
of dot1dBasePortIfIndex as another port on the
same bridge, this object contains the name of an
object instance unique to this port. For example,
in the case where multiple ports correspond one-
to-one with multiple X.25 virtual circuits, this
value might identify an (e.g., the first) object
Decker/Langille/Rijsinghani/McCloghrie [Page 15]
Internet Draft Bridge MIB October 1992
instance associated with the X.25 virtual circuit
corresponding to this port.
For a port which has a unique value of
dot1dBasePortIfIndex, this object can have the
value { 0 0 }."
::= { dot1dBasePortEntry 3 }
dot1dBasePortDelayExceededDiscards OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of frames discarded by this port due
to excessive transit delay through the bridge. It
is incremented by both transparent and source
route bridges."
REFERENCE
"IEEE 802.1D-1990: Section 6.6.1.1.3"
::= { dot1dBasePortEntry 4 }
dot1dBasePortMtuExceededDiscards OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of frames discarded by this port due
to an excessive size. It is incremented by both
transparent and source route bridges."
REFERENCE
"IEEE 802.1D-1990: Section 6.6.1.1.3"
::= { dot1dBasePortEntry 5 }
Decker/Langille/Rijsinghani/McCloghrie [Page 16]
Internet Draft Bridge MIB October 1992
-- the dot1dStp group
-- Implementation of the dot1dStp group is optional. It is
-- implemented by those bridges that support the Spanning Tree
-- Protocol.
dot1dStpProtocolSpecification OBJECT-TYPE
SYNTAX INTEGER {
unknown(1),
decLb100(2),
ieee8021d(3)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An indication of what version of the Spanning
Tree Protocol is being run. The value
'decLb100(2)' indicates the DEC LANbridge 100
Spanning Tree protocol. IEEE 802.1d
implementations will return 'ieee8021d(3)'. If
future versions of the IEEE Spanning Tree Protocol
are released that are incompatible with the
current version a new value will be defined."
::= { dot1dStp 1 }
dot1dStpPriority OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The value of the write-able portion of the Bridge
ID, i.e., the first two octets of the (8 octet
long) Bridge ID. The other (last) 6 octets of the
Bridge ID are given by the value of
dot1dBaseBridgeAddress."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.3.7"
::= { dot1dStp 2 }
dot1dStpTimeSinceTopologyChange OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
Decker/Langille/Rijsinghani/McCloghrie [Page 17]
Internet Draft Bridge MIB October 1992
"The time (in hundredths of a second) since the
last time a topology change was detected by the
bridge entity."
REFERENCE
"IEEE 802.1D-1990: Section 6.8.1.1.3"
::= { dot1dStp 3 }
dot1dStpTopChanges OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of topology changes detected by
this bridge since the management entity was last
reset or initialized."
REFERENCE
"IEEE 802.1D-1990: Section 6.8.1.1.3"
::= { dot1dStp 4 }
dot1dStpDesignatedRoot OBJECT-TYPE
SYNTAX BridgeId
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The bridge identifier of the root of the spanning
tree as determined by the Spanning Tree Protocol
as executed by this node. This value is used as
the Root Identifier parameter in all Configuration
Bridge PDUs originated by this node."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.3.1"
::= { dot1dStp 5 }
dot1dStpRootCost OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The cost of the path to the root as seen from
this bridge."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.3.2"
::= { dot1dStp 6 }
dot1dStpRootPort OBJECT-TYPE
Decker/Langille/Rijsinghani/McCloghrie [Page 18]
Internet Draft Bridge MIB October 1992
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The port number of the port which offers the
lowest cost path from this bridge to the root
bridge."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.3.3"
::= { dot1dStp 7 }
dot1dStpMaxAge OBJECT-TYPE
SYNTAX Timeout
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The maximum age of Spanning Tree Protocol
information learned from the network on any port
before it is discarded, in units of hundredths of
a second. This is the actual value that this
bridge is currently using."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.3.4"
::= { dot1dStp 8 }
dot1dStpHelloTime OBJECT-TYPE
SYNTAX Timeout
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The amount of time between the transmission of
Configuration bridge PDUs by this node on any port
when it is the root of the spanning tree or trying
to become so, in units of hundredths of a second.
This is the actual value that this bridge is
currently using."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.3.5"
::= { dot1dStp 9 }
dot1dStpHoldTime OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
Decker/Langille/Rijsinghani/McCloghrie [Page 19]
Internet Draft Bridge MIB October 1992
"This time value determines the interval length
during which no more than two Configuration bridge
PDUs shall be transmitted by this node, in units
of hundredths of a second."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.3.14"
::= { dot1dStp 10 }
dot1dStpForwardDelay OBJECT-TYPE
SYNTAX Timeout
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This time value, measured in units of hundredths
of a second, controls how fast a port changes its
spanning state when moving towards the Forwarding
state. The value determines how long the port
stays in each of the Listening and Learning
states, which precede the Forwarding state. This
value is also used, when a topology change has
been detected and is underway, to age all dynamic
entries in the Forwarding Database. [Note that
this value is the one that this bridge is
currently using, in contrast to
dot1dStpBridgeForwardDelay which is the value that
this bridge and all others would start using
if/when this bridge were to become the root.]"
REFERENCE
"IEEE 802.1D-1990: Section 4.5.3.6"
::= { dot1dStp 11 }
dot1dStpBridgeMaxAge OBJECT-TYPE
SYNTAX Timeout (600..4000)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The value that all bridges use for MaxAge when
this bridge is acting as the root. Note that
802.1D-1990 specifies that the range for this
parameter is related to the value of
dot1dStpBridgeHelloTime. The granularity of this
timer is specified by 802.1D-1990 to be 1 second.
An agent may return a badValue error if a set is
attempted to a value which is not a whole number
of seconds."
Decker/Langille/Rijsinghani/McCloghrie [Page 20]
Internet Draft Bridge MIB October 1992
REFERENCE
"IEEE 802.1D-1990: Section 4.5.3.8"
::= { dot1dStp 12 }
dot1dStpBridgeHelloTime OBJECT-TYPE
SYNTAX Timeout (100..1000)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The value that all bridges use for HelloTime when
this bridge is acting as the root. The
granularity of this timer is specified by 802.1D-
1990 to be 1 second. An agent may return a
badValue error if a set is attempted to a value
which is not a whole number of seconds."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.3.9"
::= { dot1dStp 13 }
dot1dStpBridgeForwardDelay OBJECT-TYPE
SYNTAX Timeout (400..3000)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The value that all bridges use for ForwardDelay
when this bridge is acting as the root. Note that
802.1D-1990 specifies that the range for this
parameter is related to the value of
dot1dStpBridgeMaxAge. The granularity of this
timer is specified by 802.1D-1990 to be 1 second.
An agent may return a badValue error if a set is
attempted to a value which is not a whole number
of seconds."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.3.10"
::= { dot1dStp 14 }
Decker/Langille/Rijsinghani/McCloghrie [Page 21]
Internet Draft Bridge MIB October 1992
-- The Spanning Tree Port Table
dot1dStpPortTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1dStpPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A table that contains port-specific information
for the Spanning Tree Protocol."
::= { dot1dStp 15 }
dot1dStpPortEntry OBJECT-TYPE
SYNTAX Dot1dStpPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of information maintained by every port
about the Spanning Tree Protocol state for that
port."
INDEX { dot1dStpPort }
::= { dot1dStpPortTable 1 }
Dot1dStpPortEntry ::=
SEQUENCE {
dot1dStpPort
INTEGER,
dot1dStpPortPriority
INTEGER,
dot1dStpPortState
INTEGER,
dot1dStpPortEnable
INTEGER,
dot1dStpPortPathCost
INTEGER,
dot1dStpPortDesignatedRoot
BridgeId,
dot1dStpPortDesignatedCost
INTEGER,
dot1dStpPortDesignatedBridge
BridgeId,
dot1dStpPortDesignatedPort
OCTET STRING,
dot1dStpPortForwardTransitions
Counter
}
Decker/Langille/Rijsinghani/McCloghrie [Page 22]
Internet Draft Bridge MIB October 1992
dot1dStpPort OBJECT-TYPE
SYNTAX INTEGER (1..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The port number of the port for which this entry
contains Spanning Tree Protocol management
information."
REFERENCE
"IEEE 802.1D-1990: Section 6.8.2.1.2"
::= { dot1dStpPortEntry 1 }
dot1dStpPortPriority OBJECT-TYPE
SYNTAX INTEGER (0..255)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The value of the priority field which is
contained in the first (in network byte order)
octet of the (2 octet long) Port ID. The other
octet of the Port ID is given by the value of
dot1dStpPort."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.5.1"
::= { dot1dStpPortEntry 2 }
dot1dStpPortState OBJECT-TYPE
SYNTAX INTEGER {
disabled(1),
blocking(2),
listening(3),
learning(4),
forwarding(5),
broken(6)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The port's current state as defined by
application of the Spanning Tree Protocol. This
state controls what action a port takes on
reception of a frame. If the bridge has detected
a port that is malfunctioning it will place that
port into the broken(6) state. For ports which
are disabled (see dot1dStpPortEnable), this object
Decker/Langille/Rijsinghani/McCloghrie [Page 23]
Internet Draft Bridge MIB October 1992
will have a value of disabled(1)."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.5.2"
::= { dot1dStpPortEntry 3 }
dot1dStpPortEnable OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The enabled/disabled status of the port."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.5.2"
::= { dot1dStpPortEntry 4 }
dot1dStpPortPathCost OBJECT-TYPE
SYNTAX INTEGER (1..65535)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The contribution of this port to the path cost of
paths towards the spanning tree root which include
this port. 802.1D-1990 recommends that the
default value of this parameter be in inverse
proportion to the speed of the attached LAN."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.5.3"
::= { dot1dStpPortEntry 5 }
dot1dStpPortDesignatedRoot OBJECT-TYPE
SYNTAX BridgeId
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The unique Bridge Identifier of the Bridge
recorded as the Root in the Configuration BPDUs
transmitted by the Designated Bridge for the
segment to which the port is attached."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.5.4"
::= { dot1dStpPortEntry 6 }
Decker/Langille/Rijsinghani/McCloghrie [Page 24]
Internet Draft Bridge MIB October 1992
dot1dStpPortDesignatedCost OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The path cost of the Designated Port of the
segment connected to this port. This value is
compared to the Root Path Cost field in received
bridge PDUs."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.5.5"
::= { dot1dStpPortEntry 7 }
dot1dStpPortDesignatedBridge OBJECT-TYPE
SYNTAX BridgeId
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The Bridge Identifier of the bridge which this
port considers to be the Designated Bridge for
this port's segment."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.5.6"
::= { dot1dStpPortEntry 8 }
dot1dStpPortDesignatedPort OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (2))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The Port Identifier of the port on the Designated
Bridge for this port's segment."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.5.7"
::= { dot1dStpPortEntry 9 }
dot1dStpPortForwardTransitions OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times this port has transitioned
from the Learning state to the Forwarding state."
::= { dot1dStpPortEntry 10 }
Decker/Langille/Rijsinghani/McCloghrie [Page 25]
Internet Draft Bridge MIB October 1992
-- the dot1dTp group
-- Implementation of the dot1dTp group is optional. It is
-- implemented by those bridges that support the transparent
-- bridging mode. A transparent or SRT bridge will implement
-- this group.
dot1dTpLearnedEntryDiscards OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of Forwarding Database entries,
which have been or would have been learnt, but
have been discarded due to a lack of space to
store them in the Forwarding Database. If this
counter is increasing, it indicates that the
Forwarding Database is regularly becoming full (a
condition which has unpleasant performance effects
on the subnetwork). If this counter has a
significant value but is not presently increasing,
it indicates that the problem has been occurring
but is not persistent."
REFERENCE
"IEEE 802.1D-1990: Section 6.7.1.1.3"
::= { dot1dTp 1 }
dot1dTpAgingTime OBJECT-TYPE
SYNTAX INTEGER (10..1000000)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The timeout period in seconds for aging out
dynamically learned forwarding information.
802.1D-1990 recommends a default of 300 seconds."
REFERENCE
"IEEE 802.1D-1990: Section 6.7.1.1.3"
::= { dot1dTp 2 }
Decker/Langille/Rijsinghani/McCloghrie [Page 26]
Internet Draft Bridge MIB October 1992
-- The Forwarding Database for Transparent Bridges
dot1dTpFdbTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1dTpFdbEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A table that contains information about unicast
entries for which the bridge has forwarding and/or
filtering information. This information is used
by the transparent bridging function in
determining how to propagate a received frame."
::= { dot1dTp 3 }
dot1dTpFdbEntry OBJECT-TYPE
SYNTAX Dot1dTpFdbEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Information about a specific unicast MAC address
for which the bridge has some forwarding and/or
filtering information."
INDEX { dot1dTpFdbAddress }
::= { dot1dTpFdbTable 1 }
Dot1dTpFdbEntry ::=
SEQUENCE {
dot1dTpFdbAddress
MacAddress,
dot1dTpFdbPort
INTEGER,
dot1dTpFdbStatus
INTEGER
}
dot1dTpFdbAddress OBJECT-TYPE
SYNTAX MacAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A unicast MAC address for which the bridge has
forwarding and/or filtering information."
REFERENCE
"IEEE 802.1D-1990: Section 3.9.1, 3.9.2"
::= { dot1dTpFdbEntry 1 }
Decker/Langille/Rijsinghani/McCloghrie [Page 27]
Internet Draft Bridge MIB October 1992
dot1dTpFdbPort OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Either the value '0', or the port number of the
port on which a frame having a source address
equal to the value of the corresponding instance
of dot1dTpFdbAddress has been seen. A value of
'0' indicates that the port number has not been
learned but that the bridge does have some
forwarding/filtering information about this
address (e.g. in the dot1dStaticTable).
Implementors are encouraged to assign the port
value to this object whenever it is learned even
for addresses for which the corresponding value of
dot1dTpFdbStatus is not learned(3)."
::= { dot1dTpFdbEntry 2 }
dot1dTpFdbStatus OBJECT-TYPE
SYNTAX INTEGER {
other(1),
invalid(2),
learned(3),
self(4),
mgmt(5)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The status of this entry. The meanings of the
values are:
other(1) : none of the following. This would
include the case where some other
MIB object (not the corresponding
instance of dot1dTpFdbPort, nor an
entry in the dot1dStaticTable) is
being used to determine if and how
frames addressed to the value of
the corresponding instance of
dot1dTpFdbAddress are being
forwarded.
invalid(2) : this entry is not longer valid
Decker/Langille/Rijsinghani/McCloghrie [Page 28]
Internet Draft Bridge MIB October 1992
(e.g., it was learned but has since
aged-out), but has not yet been
flushed from the table.
learned(3) : the value of the corresponding
instance of dot1dTpFdbPort was
learned, and is being used.
self(4) : the value of the corresponding
instance of dot1dTpFdbAddress
represents one of the bridge's
addresses. The corresponding
instance of dot1dTpFdbPort
indicates which of the bridge's
ports has this address.
mgmt(5) : the value of the corresponding
instance of dot1dTpFdbAddress is
also the value of an existing
instance of dot1dStaticAddress."
::= { dot1dTpFdbEntry 3 }
-- Port Table for Transparent Bridges
dot1dTpPortTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1dTpPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A table that contains information about every
port that is associated with this transparent
bridge."
::= { dot1dTp 4 }
dot1dTpPortEntry OBJECT-TYPE
SYNTAX Dot1dTpPortEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of information for each port of a
transparent bridge."
INDEX { dot1dTpPort }
::= { dot1dTpPortTable 1 }
Decker/Langille/Rijsinghani/McCloghrie [Page 29]
Internet Draft Bridge MIB October 1992
Dot1dTpPortEntry ::=
SEQUENCE {
dot1dTpPort
INTEGER,
dot1dTpPortMaxInfo
INTEGER,
dot1dTpPortInFrames
Counter,
dot1dTpPortOutFrames
Counter,
dot1dTpPortInDiscards
Counter
}
dot1dTpPort OBJECT-TYPE
SYNTAX INTEGER (1..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The port number of the port for which this entry
contains Transparent bridging management
information."
::= { dot1dTpPortEntry 1 }
-- It would be nice if we could use ifMtu as the size of the
-- largest INFO field, but we can't because ifMtu is defined
-- to be the size that the (inter-)network layer can use which
-- can differ from the MAC layer (especially if several layers
-- of encapsulation are used).
dot1dTpPortMaxInfo OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The maximum size of the INFO (non-MAC) field that
this port will receive or transmit."
::= { dot1dTpPortEntry 2 }
dot1dTpPortInFrames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of frames that have been received by
Decker/Langille/Rijsinghani/McCloghrie [Page 30]
Internet Draft Bridge MIB October 1992
this port from its segment. Note that a frame
received on the interface corresponding to this
port is only counted by this object if and only if
it is for a protocol being processed by the local
bridging function, including bridge management
frames."
REFERENCE
"IEEE 802.1D-1990: Section 6.6.1.1.3"
::= { dot1dTpPortEntry 3 }
dot1dTpPortOutFrames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of frames that have been transmitted
by this port to its segment. Note that a frame
transmitted on the interface corresponding to this
port is only counted by this object if and only if
it is for a protocol being processed by the local
bridging function, including bridge management
frames."
REFERENCE
"IEEE 802.1D-1990: Section 6.6.1.1.3"
::= { dot1dTpPortEntry 4 }
dot1dTpPortInDiscards OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Count of valid frames received which were
discarded (i.e., filtered) by the Forwarding
Process."
REFERENCE
"IEEE 802.1D-1990: Section 6.6.1.1.3"
::= { dot1dTpPortEntry 5 }
Decker/Langille/Rijsinghani/McCloghrie [Page 31]
Internet Draft Bridge MIB October 1992
-- The Static (Destination-Address Filtering) Database
-- Implementation of this group is optional.
dot1dStaticTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1dStaticEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A table containing filtering information
configured into the bridge by (local or network)
management specifying the set of ports to which
frames received from specific ports and containing
specific destination addresses are allowed to be
forwarded. The value of zero in this table as the
port number from which frames with a specific
destination address are received, is used to
specify all ports for which there is no specific
entry in this table for that particular
destination address. Entries are valid for
unicast and for group/broadcast addresses."
REFERENCE
"IEEE 802.1D-1990: Section 6.7.2"
::= { dot1dStatic 1 }
dot1dStaticEntry OBJECT-TYPE
SYNTAX Dot1dStaticEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Filtering information configured into the bridge
by (local or network) management specifying the
set of ports to which frames received from a
specific port and containing a specific
destination address are allowed to be forwarded."
REFERENCE
"IEEE 802.1D-1990: Section 6.7.2"
INDEX { dot1dStaticAddress, dot1dStaticReceivePort }
::= { dot1dStaticTable 1 }
Dot1dStaticEntry ::=
SEQUENCE {
dot1dStaticAddress
MacAddress,
Decker/Langille/Rijsinghani/McCloghrie [Page 32]
Internet Draft Bridge MIB October 1992
dot1dStaticReceivePort
INTEGER,
dot1dStaticAllowedToGoTo
OCTET STRING,
dot1dStaticStatus
INTEGER
}
dot1dStaticAddress OBJECT-TYPE
SYNTAX MacAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The destination MAC address in a frame to which
this entry's filtering information applies. This
object can take the value of a unicast address, a
group address or the broadcast address."
REFERENCE
"IEEE 802.1D-1990: Section 3.9.1, 3.9.2"
::= { dot1dStaticEntry 1 }
dot1dStaticReceivePort OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Either the value '0', or the port number of the
port from which a frame must be received in order
for this entry's filtering information to apply.
A value of zero indicates that this entry applies
on all ports of the bridge for which there is no
other applicable entry."
::= { dot1dStaticEntry 2 }
dot1dStaticAllowedToGoTo OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The set of ports to which frames received from a
specific port and destined for a specific MAC
address, are allowed to be forwarded. Each octet
within the value of this object specifies a set of
eight ports, with the first octet specifying ports
1 through 8, the second octet specifying ports 9
Decker/Langille/Rijsinghani/McCloghrie [Page 33]
Internet Draft Bridge MIB October 1992
through 16, etc. Within each octet, the most
significant bit represents the lowest numbered
port, and the least significant bit represents the
highest numbered port. Thus, each port of the
bridge is represented by a single bit within the
value of this object. If that bit has a value of
'1' then that port is included in the set of
ports; the port is not included if its bit has a
value of '0'. (Note that the setting of the bit
corresponding to the port from which a frame is
received is irrelevant.) The default value of
this object is a string of ones of appropriate
length."
::= { dot1dStaticEntry 3 }
dot1dStaticStatus OBJECT-TYPE
SYNTAX INTEGER {
other(1),
invalid(2),
permanent(3),
deleteOnReset(4),
deleteOnTimeout(5)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This object indicates the status of this entry.
The default value is permanent(3).
other(1) - this entry is currently in use but
the conditions under which it will
remain so are different from each of the
following values.
invalid(2) - writing this value to the object
removes the corresponding entry.
permanent(3) - this entry is currently in use
and will remain so after the next reset
of the bridge.
deleteOnReset(4) - this entry is currently in
use and will remain so until the next
reset of the bridge.
deleteOnTimeout(5) - this entry is currently
in use and will remain so until it is
aged out."
::= { dot1dStaticEntry 4 }
Decker/Langille/Rijsinghani/McCloghrie [Page 34]
Internet Draft Bridge MIB October 1992
-- Traps for use by Bridges
-- Traps for the Spanning Tree Protocol
newRoot TRAP-TYPE
ENTERPRISE dot1dBridge
DESCRIPTION
"The newRoot trap indicates that the sending agent
has become the new root of the Spanning Tree; the
trap is sent by a bridge soon after its election
as the new root, e.g., upon expiration of the
Topology Change Timer immediately subsequent to
its election. Implementation of this trap is
optional."
::= 1
topologyChange TRAP-TYPE
ENTERPRISE dot1dBridge
DESCRIPTION
"A topologyChange trap is sent by a bridge when
any of its configured ports transitions from the
Learning state to the Forwarding state, or from
the Forwarding state to the Blocking state. The
trap is not sent if a newRoot trap is sent for the
same transition. Implementation of this trap is
optional."
::= 2
END
Decker/Langille/Rijsinghani/McCloghrie [Page 35]
Internet Draft Bridge MIB October 1992
8. Acknowledgments
This document was produced on behalf of the Bridge Sub-Working
Group of the SNMP Working Group of the Internet Engineering
Task Force. Over the course of its deliberations, the working
group received four separate documents for consideration as
the basis for its work. The first was submitted by Stan Froyd
of Advanced Computer Communications; the second by Richard Fox
of SynOptics; the third by Eric Decker of cisco Inc. and Keith
McCloghrie of Hughes LAN Systems; and the fourth by Paul
Langille and Anil Rijsinghani of Digital Equipment Corp. After
considering the submissions, the working group chose to
proceed with a document formed as a conjunction of the latter
two submissions. This document is the result.
The authors wish to thank the members of the Bridge Working
Group for their many comments and suggestions which improved
this effort. In particular, Fred Baker (chairman of the
working group) of ACC, Steve Sherry of Xyplex, and Frank
Kastenholz of Clearpoint Research Corp. Others members of the
Bridge Working Group who contributed to this effort are:
Bill Anderson, Mitre
Karl Auerbach, Epilogue
Fred Baker, ACC (chair)
Terry Bradley, Wellfleet
Ted Brunner, Bellcore
Jeffrey Buffum, Apollo
Chris ChioTasso, Fibronics
Anthony Chung, HLS
Chuck Davin, MIT-LCS
Andy Davis, Spider
Eric Decker, cisco
Nadya El-Afandi, Network Systems
Gary Ellis,HP/Apollo
Richard Fox, SynOptics
Stan Froyd, ACC
Frank Kastenholz, Clearpoint Research
Shirnshon Kaufman,
Jim Kinder, Fibercom
Cheryl Krupczak,NCR
Paul Langille, Digital
Peter Lin,Vitalink
Keith McCloghrie, HLS
Donna McMaster, SynOptics
Decker/Langille/Rijsinghani/McCloghrie [Page 36]
Internet Draft Bridge MIB October 1992
Dave Perkins, 3Com
Jim Reinstedler, Ungermann Bass
Anil Rijsinghani, Digital
Mark Schaefer, David Systems
Steve Sherry, Xyplex
Bob Stewart, Xyplex
Emil Sturniolo,
Kevin Synott, Retix
Ian Thomas, Chipcom
Maurice Turcott, Racal
Fei Xu,
Decker/Langille/Rijsinghani/McCloghrie [Page 37]
Internet Draft Bridge MIB October 1992
9. References
[1] V. Cerf, IAB Recommendations for the Development of
Internet Network Management Standards. Internet Working
Group Request for Comments 1052. Network Information
Center, SRI International, Menlo Park, California,
(April, 1988).
[2] V. Cerf, Report of the Second Ad Hoc Network Management
Review Group, Internet Working Group Request for Comments
1109. Network Information Center, SRI International,
Menlo Park, California, (August, 1989).
[3] M.T. Rose and K. McCloghrie, Structure and Identification
of Management Information for TCP/IP-based internets,
Internet Working Group Request for Comments 1155.
Network Information Center, SRI International, Menlo
Park, California, (May, 1990).
[4] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
Simple Network Management Protocol, Internet Working
Group Request for Comments 1157. Network Information
Center, SRI International, Menlo Park, California, (May,
1990).
[5] K. McCloghrie and M.T. Rose (editors), Management
Information Base for Network Management of TCP/IP-based
internets: MIB-II, Internet Working Group Request for
Comments 1213. Network Information Center, SRI
International, Menlo Park, California, (March, 1991).
[6] Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization. International Standard 8824, (December,
1987).
[7] Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules
for Abstract Notation One (ASN.1), International
Organization for Standardization. International Standard
8825, (December, 1987).
[8] M.T. Rose, K. McCloghrie (editors), Concise MIB
Definitions, Internet Working Group Request for Comments
Decker/Langille/Rijsinghani/McCloghrie [Page 38]
Internet Draft Bridge MIB October 1992
1212. Network Information Center, SRI International,
Menlo Park, California, (March, 1991).
[9] M.T. Rose (editor), A Convention for Defining Traps for
use with the SNMP, Internet Working Group Request for
Comments 1215. Network Information Center, SRI
International, Menlo Park, California, (March, 1991).
[10] ANSI/IEEE Standard 802.1D-1990 MAC Bridges, IEEE Project
802 Local and Metropolitan Area Networks, (March 8,
1991).
[11] ISO DIS 10038 MAC Bridges
Decker/Langille/Rijsinghani/McCloghrie [Page 39]
Internet Draft Bridge MIB October 1992
Table of Contents
1 Abstract .............................................. 1
2 Status of this Memo ................................... 1
3 The Network Management Framework ...................... 2
4 Objects ............................................... 2
4.1 Format of Definitions ............................... 3
5 Overview .............................................. 4
5.1 Structure of MIB .................................... 4
5.1.1 The dot1dBase Group ............................... 7
5.1.2 The dot1dStp Group ................................ 7
5.1.3 The dot1dSr Group ................................. 7
5.1.4 The dot1dTp Group ................................. 7
5.1.5 The dot1dStatic Group ............................. 7
5.2 Relationship to Other MIBs .......................... 8
5.2.1 Relationship to the 'system' group ................ 8
5.2.2 Relationship to the 'interfaces' group ............ 8
5.3 Textual Conventions ................................. 9
6 Changes from RFC 1286 ................................. 9
7 Definitions ........................................... 11
7.1 Groups in the Bridge MIB ............................ 12
7.2 The dot1dBase Group Definitions ..................... 13
7.3 The dot1dStp Group Definitions ...................... 17
7.4 The dot1dTp Group Definitions ....................... 26
7.5 The dot1dStatic Group Definitions ................... 32
7.6 Traps for use by Bridges ............................ 35
8 Acknowledgments ....................................... 36
9 References ............................................ 38
Draft Expiration Date: March 1993
Decker/Langille/Rijsinghani/McCloghrie [Page 40]